Apparatus and methods for widget update scheduling

ABSTRACT

Methods and apparatus for scheduling a content update of a mobile widget are provided. The method may include receiving a widget update consideration. The method may also include generating a content update schedule for a mobile widget based on the update consideration. Further, the method may include storing the generated content update schedule for use in updating a content of the mobile widget.

CLAIM OF PRIORITY UNDER 35 U.S.C. §119

The present Application for patent claims priority to ProvisionalApplication No. 61/039,402 entitled “APPARATUS AND METHODS OF MANAGINGWIDGETS IN A WIRELESS COMMUNICATION ENVIRONMENT” filed Mar. 25, 2008,and hereby expressly incorporated by reference herein.

REFERENCE TO CO-PENDING APPLICATIONS FOR PATENT

The present Application for Patent is related to the followingco-pending U.S. Patent Applications:

U.S. patent application Ser. No. 12/407,583, entitled “APPARATUS ANDMETHODS FOR TRANSPORT OPTIMIZATION FOR WIDGET CONTENT DELIVERY”, filedconcurrently herewith, and expressly incorporated by reference herein;

U.S. patent application Ser. No. 12/407,567, entitled “APPARATUS ANDMETHODS FOR WIDGET-RELATED MEMORY MANAGEMENT”, filed concurrentlyherewith, and expressly incorporated by reference herein;

U.S. patent application Ser. No. 12/407,559, entitled “APPARATUS ANDMETHODS FOR MANAGING WIDGETS IN A WIRELESS COMMUNICATION ENVIRONMENT”,filed concurrently herewith, and expressly incorporated by referenceherein; and

U.S. patent application Ser. No. 12/407,593, entitled “APPARATUS ANDMETHODS FOR WIDGET INTERCOMMUNICATION IN A WIRELESS COMMUNICATIONENVIRONMENT”, filed concurrently herewith, and expressly incorporated byreference herein.

BACKGROUND

The described aspects relate to widgets, and more specifically toapparatus and methods relating to widget-related update scheduling in awireless communication environment.

Wireless networking systems have become a prevalent way to communicatewith others worldwide. Wireless communication devices, such as a mobileor cellular telephone, a personal digital assistant (PDA), etc., operateon such networks, and have become smaller and more powerful in order tomeet consumer needs and to improve portability and convenience.Consumers have become dependent upon these devices, demanding reliableservice, expanded areas of coverage, additional services such as webbrowsing capabilities, and continued reduction in the size and cost ofsuch devices.

Many of the functionalities and end user experiences of wirelesscommunication devices have been developed, with limited success, tomimic the functionalities and end user experiences of a personalcomputing (PC) environment. For example, mobile web services have seenvarying levels of success, even with the deployment of relatively highspeed and high capacity services, such as advanced 3G services (1×-EV-DORev. A, UMTS HSPA). Much of the problem lies in the fact that the mobileweb browsing experience is distinct from the PC experience with whichmost users are familiar. In particular, many end users find mobile webbrowsing applications to be hard to use, for example, with regard toentering search information, and difficult to enjoy, for example, as theresulting presentation of content is unpleasant.

Additionally, desktop widgets usually access content using the standardXML HTTP Request (XHR) mechanism, or a variant thereof, which requiresdata to be delivered immediately following the execution of the XHR. Ina limited throughput environment, such as in a wireless communicationnetwork, e.g. a cellular network, this mechanism often results insignificant and perceptible delay to the end user in rendering requestedcontent.

Therefore, apparatus and methods are desired to improve the experienceof an end user in interacting with web services on a wirelesscommunication device.

SUMMARY

The following presents a simplified summary of one or more aspects inorder to provide a basic understanding of such aspects. This summary isnot an extensive overview of all contemplated aspects, and is intendedto neither identify key or critical elements of all aspects nordelineate the scope of any or all aspects. Its sole purpose is topresent some concepts of one or more aspects in a simplified form as aprelude to the more detailed description that is presented later.

One aspect relates to a method for scheduling a content update of amobile widget. The method may include receiving a widget updateconsideration. The method may also include generating a content updateschedule for a mobile widget based on the update consideration. Further,the method may include storing the generated content update schedule foruse in updating a content of the mobile widget.

Another aspect relates to at least one processor configured to schedulea content update of a mobile widget. The processor may include a firstmodule for receiving a widget update consideration. Further, theprocessor may include a second module for generating a content updateschedule for a mobile widget based on the update consideration.Additionally, the processor may include a third module for storing thegenerated content update schedule for use in updating a content of themobile widget.

Yet another aspect relates to a computer program product for schedulinga content update of a mobile widget. The computer program product mayinclude a computer-readable medium including at least one instructionfor causing a computer to receive a widget update consideration. Thecomputer-readable medium may also include at least one instruction forcausing the computer to generate a content update schedule for a mobilewidget based on the update consideration. Moreover, thecomputer-readable medium may include at least one instruction forcausing the computer to generate content update schedule for use inupdating a content of the mobile widget.

Another aspect relates to a network device for scheduling a contentupdate of a mobile widget. The network device may include means forreceiving a widget update consideration. Additionally, the networkdevice may include means for generating a content update schedule for amobile widget based on the update consideration. The network device mayalso include means for storing the generated content update schedule foruse in updating a content of the mobile widget.

Yet another aspect relates to a network device for scheduling a contentupdate of a mobile widget. The network device may include acommunication module operable to receive a widget update consideration.Moreover, the network device may include an update scheduling manageroperable to generate a content update schedule for a mobile widget basedon the update consideration. Further, the network device may include adatabase operable to store the generated content update schedule for usein updating a content of the mobile widget.

Still another aspect relates to a method of updating content of a mobilewidget on a wireless device. The method may include obtaining a mobilewidget. The method may also include receiving a content update schedulefor use in updating a content of the mobile widget, wherein the contentupdate schedule is generated based on an update consideration. Further,the method may include receiving a content update based on the contentupdate schedule. Additionally, the method may include storing thecontent update.

Another aspect relates to at least one processor configured to updatecontent of a mobile widget. The processor may include a first module forobtaining a mobile widget. In addition, the processor may include asecond module for receiving a content update schedule for use inupdating a content of the mobile widget, wherein the content updateschedule is generated based on an update consideration. Moreover, theprocessor may include a third module for receiving a content updatebased on the content update schedule. Furthermore, the processor mayinclude a fourth module for storing the content update.

Yet another aspect relates to a computer program product for updatingcontent of a mobile widget including a computer-readable medium. Thecomputer-readable medium may include at least one instruction forcausing a computer to obtain a mobile widget. Further, thecomputer-readable medium may include at least one instruction forcausing the computer to receive a content update schedule for use inupdating a content of the mobile widget, wherein the content updateschedule is generated based on an update consideration. Thecomputer-readable medium may also include at least one instruction forcausing the computer to receive a content update based on the contentupdate schedule. In addition, the computer-readable medium may includeat least one instruction for causing the computer to store the contentupdate.

Another aspect relates to a wireless device for updating content of amobile widget. The wireless device may include means for obtaining amobile widget. The wireless device may also include means for receivinga content update schedule for use in updating a content of the mobilewidget, wherein the content update schedule is generated based on anupdate consideration. Moreover, the wireless device may include meansfor receiving a content update based on the content update schedule.Further, the wireless device may include means for storing the contentupdate.

Still another aspect relates to a wireless communication device. Thewireless communication device may include a memory comprising a widgetmanagement client. In addition, the wireless communication device mayinclude a processor in communication with the memory and operable toexecute the widget management client, wherein the widget managementclient is operable to obtain a mobile widget, wherein the widgetmanagement client is further operable to receive a content updateschedule for use in updating a content of the mobile widget, wherein thecontent update schedule is generated based on an update consideration,wherein the widget management client is further operable to receive acontent update based on the content update schedule. Further, thewireless communication device may include a database operable to storethe content update.

To the accomplishment of the foregoing and related ends, the one or moreaspects comprise the features hereinafter fully described andparticularly pointed out in the claims. The following description andthe annexed drawings set forth in detail certain illustrative featuresof the one or more aspects. These features are indicative, however, ofbut a few of the various ways in which the principles of various aspectsmay be employed, and this description is intended to include all suchaspects and their equivalents.

BRIEF DESCRIPTION OF THE DRAWINGS

The disclosed aspects will hereinafter be described in conjunction withthe appended drawings, provided to illustrate and not to limit thedisclosed aspects, wherein like designations denote like elements, andin which:

FIG. 1 is a schematic diagram of an aspect of an end-to-end mobilewidget system;

FIG. 2 is a schematic representation of an aspect of a wireless devicehaving a display with a number of mobile widgets in a first state;

FIG. 3 is a schematic representation of an aspect of the wireless deviceof FIG. 2 with one of the mobile widgets in a second state;

FIG. 4 is a schematic diagram of an aspect of a network device of thesystem of FIG. 1;

FIG. 5 is a schematic diagram of an aspect of the unified widget manager(UWM) of FIG. 1;

FIG. 6 is a schematic diagram of an aspect of an auction architecture ofthe system of FIG. 1;

FIG. 7 is flow diagram of an aspect of an auction method of the systemof FIG. 1;

FIG. 8 is a schematic diagram of an aspect of the widget managementsystem (WMS) of FIG. 1;

FIG. 9 is a schematic diagram of an aspect of the message router of FIG.1;

FIG. 10 is a schematic diagram of an aspect of the wireless device ofFIG. 1;

FIG. 11 is a schematic diagram of an aspect of the widget managementclient (WMC) of FIG. 1;

FIG. 12 is a schematic diagram of an aspect of a widget usage reporterof the system of FIG. 1;

FIG. 13 is a schematic diagram of an aspect of a widget wizard of theWMC of FIG. 11;

FIG. 14 is a schematic diagram of an aspect of a widget advertisement ofthe system of FIG. 1;

FIG. 15 is a schematic diagram of an aspect of an advertisingarchitecture of the system of FIG. 1;

FIG. 16 is a schematic diagram of an aspect of a widget configurationarchitecture of the system of FIG. 1;

FIG. 17 is a schematic diagram of an aspect of a content access serverof the system of FIG. 1;

FIG. 18 is a call flow relating to an aspect of selecting and updating amobile widget in the system of FIG. 1;

FIG. 19 is a call flow relating to an aspect of selecting and updating amobile widget in the system of FIG. 1;

FIG. 20 is a call flow of relating to an aspect of operator/carriercontrol of access to mobile widgets in the system of FIG. 1;

FIG. 21 is a call flow of relating to an aspect of updating a mobilewidget in the system of FIG. 1;

FIG. 22 is a call flow of relating to an aspect of adjusting a contentupdate schedule for a mobile widget or an end user in the system of FIG.1;

FIG. 23 is a call flow of relating to an aspect of updating a mobilewidget in the system of FIG. 1;

FIG. 24 is a schematic diagram of an aspect of optimizing an contentupdate schedule in the system of FIG. 1;

FIG. 25 is a flow diagram of an aspect of a method of optimizing ancontent update schedule in the system of FIG. 1;

FIG. 26 is a flow diagram of an aspect of a method of optimizing ancontent update schedule in the system of FIG. 1;

FIG. 27 is an illustration of an example system that facilitatesscheduling a content update of a mobile widget; and

FIG. 28 is an illustration of an example system that facilitatesupdating a content of a mobile widget.

DETAILED DESCRIPTION

Various aspects are now described with reference to the drawings. In thefollowing description, for purposes of explanation, numerous specificdetails are set forth in order to provide a thorough understanding ofone or more aspects. It may be evident, however, that such aspect(s) maybe practiced without these specific details.

The described aspects relate to widgets, and more specifically toapparatus and methods relating to scheduling a content update of amobile widget and updating content of a mobile widget. The describedaspects may include generating a content update schedule for a mobilewidget based on an update consideration.

As used in this application, the terms “component,” “module,” “system”and the like are intended to include a computer-related entity, such asbut not limited to hardware, firmware, a combination of hardware andsoftware, software, or software in execution. For example, a componentmay be, but is not limited to being, a process running on a processor, aprocessor, an object, an executable, a thread of execution, a program,and/or a computer. By way of illustration, both an application runningon a computing device and the computing device can be a component. Oneor more components can reside within a process and/or thread ofexecution and a component may be localized on one computer and/ordistributed between two or more computers. In addition, these componentscan execute from various computer readable media having various datastructures stored thereon. The components may communicate by way oflocal and/or remote processes such as in accordance with a signal havingone or more data packets, such as data from one component interactingwith another component in a local system, distributed system, and/oracross a network such as the Internet with other systems by way of thesignal.

In the subject description, the word “exemplary” is used to mean servingas an example, instance, or illustration. Any aspect or design describedherein as “exemplary” is not necessarily to be construed as preferred oradvantageous over other aspects or designs. Rather, use of the wordexemplary is intended to present concepts in a concrete fashion.

Furthermore, various aspects are described herein in connection with aterminal, which can be a wired terminal or a wireless terminal. Aterminal can also be called a system, device, subscriber unit,subscriber station, mobile station, mobile, mobile device, remotestation, remote terminal, access terminal, user terminal, terminal,communication device, user agent, user device, or user equipment (UE). Awireless terminal may be a cellular telephone, a satellite phone, acordless telephone, a Session Initiation Protocol (SIP) phone, awireless local loop (WLL) station, a personal digital assistant (PDA), ahandheld device having wireless connection capability, a computingdevice, or other processing devices connected to a wireless modem.Moreover, various aspects are described herein in connection with a basestation. A base station may be utilized for communicating with wirelessterminal(s) and may also be referred to as an access point, a Node B, orsome other terminology.

Moreover, the term “or” is intended to mean an inclusive “or” ratherthan an exclusive “or.” That is, unless specified otherwise, or clearfrom the context, the phrase “X employs A or B” is intended to mean anyof the natural inclusive permutations. That is, the phrase “X employs Aor B” is satisfied by any of the following instances: X employs A; Xemploys B; or X employs both A and B. In addition, the articles “a” and“an” as used in this application and the appended claims shouldgenerally be construed to mean “one or more” unless specified otherwiseor clear from the context to be directed to a singular form.

The techniques described herein may be used for various wirelesscommunication systems such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA and othersystems. The terms “system” and “network” are often usedinterchangeably. A CDMA system may implement a radio technology such asUniversal Terrestrial Radio Access (UTRA), cdma2000, etc. UTRA includesWideband-CDMA (W-CDMA) and other variants of CDMA. Further, cdma2000covers IS-2000, IS-95, and IS-856 standards. A TDMA system may implementa radio technology such as Global System for Mobile Communications(GSM). An OFDMA system may implement a radio technology such as EvolvedUTRA (E-UTRA), Ultra Mobile Broadband (UMB), IEEE 802.11 (Wi-Fi), IEEE802.16 (WiMAX), IEEE 802.20, Flash-OFDM, etc. UTRA and E-UTRA are partof Universal Mobile Telecommunication System (UMTS). 3GPP Long TermEvolution (LTE) is a release of UMTS that uses E-UTRA, which employsOFDMA on the downlink and SC-FDMA on the uplink. UTRA, E-UTRA, UMTS,LTE, and GSM are described in documents from an organization named “3rdGeneration Partnership Project” (3GPP). Additionally, cdma2000 and UMBare described in documents from an organization named “3rd GenerationPartnership Project 2” (3GPP2). Further, such wireless communicationsystems may additionally include peer-to-peer (e.g., mobile-to-mobile)ad hoc network systems often using unpaired unlicensed spectrums, 802.xxwireless LAN, BLUETOOTH and any other short- or long-range, wirelesscommunication techniques.

Various aspects or features will be presented in terms of systems thatmay include a number of devices, components, modules, and the like. Itis to be understood and appreciated that the various systems may includeadditional devices, components, modules, etc. and/or may not include allof the devices, components, modules etc. discussed in connection withthe figures. A combination of these approaches may also be used.

TERMINOLOGY

To enhance the description of the present aspects, the followingprovides a list of some of the discussed terminology.

Mobile widget or widget: a user interface (UI) element with which adevice end user interacts; in some aspects, a mobile widget may have aspecific relationship with a respective content source. For example, amobile widget or widget is a relatively small, specialized graphicaluser interface (GUI) application, which may include a combination of agraphical symbol and program code or a software module executable toprovide visual information or easy access to a function, such as but notlimited to a clock, a calendar, a news aggregator, weather information,etc.

Widget frame: a static user interface display area of a mobile widget.

Widget management client (WMC): a client application that instantiatesand manages one or more mobile widgets.

Widget wall: an initial view in the WMC where a device end user can seeall or some portion of mobile widgets, depending on the size of the viewand the size of the respective mobile widgets, resident on therespective wireless communication device.

Widget operation modes: (i) compressed mode: an individual widget framefor display on a widget wall; and (ii) expanded mode: an individualwidget frame for display when the mobile widget is selected, where thewidget frame may be sized larger than the respective widget frame in thecompressed mode.

Mobile widget types: (i) updateable widget: a widget whose underlyingwidget package can be updated after instantiation at the client; (ii)locked widget: widget that cannot be modified, deleted or re-positionedby the user; it is updateable, but not at user discretion; (iii) dynamicwidget mobile widget having: a compressed mode appearance on UI that canbe manipulated by end user (as opposed to a locked widget); (iv)floating widget: a mobile widget having a compressed mode appearancethat cannot be modified by the end user; (v) discovery widget: a mobilewidget that presents widget management functionality to the end user,including widget selection and widget wall management.

Widget security: (i) trusted widget: a widget that has gone through anapproval process; and (ii) untrusted widget: a widget that has not gonethrough any approval; could be user defined, public domain, or from adeveloper.

Standalone ad widget: an optional form of a locked widget displayed onthe widget wall; may have content relevant to the end user based on,among other things, other widget selections made by the WMC.

Widget management system (WMS): an infrastructure element for managingwidget subscriptions and downloads.

Widget management portal (WMP): in one aspect, an end user-facing webtool for end users to manage widgets.

Content access server (CAS): an infrastructure element operable tohandle routing of metering information related to mobile widget activityor end user interactivity with mobile widgets from one or more wirelesscommunication devices; further operable to manage providing contentupdates to mobile widgets, and to retrieve/cache corresponding contentupdates from one or more content providers.

Widget wizard: a client management engine for mobile widgets.

Unified widget manager (UWM): an infrastructure element that operates asa clearinghouse for mobile widgets.

Message router: a network element through which all communicationbetween the widget system infrastructure elements and the WMC is routed.

Schedule record: a data record that provides update schedules for widgetcontent updates and a timetable for periodic retrieval of digital lockercontents, where the digital locker may be a WMS component that includesmobile widget information and configuration for end users; for example,the schedule record may be sent from the WMS digital locker to the WMC.

Catalog record: a data record sent from the WMS digital locker to theWMC and WMP that provides a widget catalog listing mobile widgets, e.g.catalog items, available to the end user; the catalog record may becustomized for an end user.

OVERVIEW

The described aspects relate to widgets, and more specifically toapparatus and methods relating to an end-to-end system for the creation,storage, delivery, and management of user-defined mobile widgets andwidget-related content in a wireless communication environment. Thedescribed aspects provide apparatus and methods enable end users tocustomize mobile widgets. Further, the described aspects provideapparatus and methods that are operable to operate efficiently in awireless network environment having constraints with regard to networkconnectivity, communications bandwidth or throughput, and wirelessdevice memory and processing usage.

As such, the described aspects particularly relate to “mobile” widgetsoptimized for a wireless network environment. To understand mobilewidgets, one should also understand their counterpart—desktop widgets.Desktop widgets are essentially compact, client applications thatprovide specific functionality to the end user via a specialized userinterface. It should be understood, however, that mobile widgets are nota straightforward extension of desktop widgets, particularly in severalrespects: (a) Desktop widgets are simple to write, and leverage existingweb programming technologies (particularly Javascript, XML, etc.). Insome aspects, mobile widgets may include compact protocols and utilizelimited interpreters (e.g. Javascript, etc.) due to limitations indevice memory and processing power; (b) Desktop widgets generallyfunction with an expectation of consistent connectivity. Such consistentconnectivity is not necessarily feasible in the wireless networkenvironment due to inconsistent available throughput, limited cellularcapacity, and specific wireless data plans; (c) Functionality utilizedby desktop widgets specified in standard Javascript (e.g. ECMAScriptversions, etc.) does not interface with wireless device-specific API'sthat can be extended to the mobile widget developer; examples of suchAPI's include the handset power meter, location information, andwireless connectivity status; (d) In some aspects, mobile widgetaccessibility may be provided in several forms, while, in general,desktop widgets are accessible directly on the PC desktop. In someaspects, mobile widgets are accessible via the wireless deviceapplication manager, while in other aspects mobile widgets may beaccessible via a specific mobile widget management application or via anetwork portal; and (e) Mobile widget discovery and instantiation may becontrolled by a wireless device application manager, or by a mobilewidget management application, or by a network portal; in contrast,desktop widget discovery and instantiation is not restricted to oneclient or one portal. Therefore, the described aspects take theseconsiderations into account to provide a mobile widget service optimizedfor the wireless network environment.

In particular, the described mobile widgets provide an alternative tothe mobile browser to access content on a wireless device, and alsoallow individual users to easily create custom mobile widgets forarbitrary wireless device or web resources.

Thus, the described aspects offer a true replacement to receivingcontent via a mobile browser, addressing the above-noted challenges bydeveloping a system with the constraints of wireless access, wirelessdevice capabilities, and web development in mind.

End-to-End System Architecture

Referring to FIGS. 1-3, in one non-limiting aspect, a mobile widgetsystem 100 provides an end-to-end architecture for the creation,storage, delivery, operation, and management of mobile widgets in awireless network environment.

A mobile widget 102 includes a compact application or set of codesexecutable by a wireless communication device 700 to interact with acontent source, such as a content access server (CAS) 900, to retrievecontent for presentation to a device end user 104 via a user interface702, such as a display, on the device. In one non-limiting aspect, forexample, mobile widget 102 may be a Really Simple Syndication (RSS)reader operable to retrieve a data feed from a news source and displaythe corresponding news item or headline(s) to allow end user 104 to viewthe latest news.

It should be noted, however, that mobile widget 102 is not limited tothe prior example, and may have any functionality and may include anytype of content. For example, mobile widget 102 may present any contentgenerated by a content provider 902, including text, graphics, audio,video, and multimedia content, etc. Further, for example, contentpresentable by mobile widget 102 may include an advertisement, such asfrom an advertisement serving platform 1000, where the advertisement maybe mixed with other content or may be the sole content. Advertisementserving platform 1000 may be a specialized version of content provider902, supplying system 100 with advertising content, managing theplacement of advertisements in system 100, and tracking feedbackrelating to the usage of advertisements on wireless communicationdevices 700. Additionally, advertisement serving platform 1000 may beoperable to interface with an advertisement virtual negotiationcomponent 1002, such as an advertisement bidding exchange, whichprovides advertisers 1004 and an operator 110 of system 100 with avirtual marketplace to enable the placement and management ofadvertising content within system 100.

Further, in system 100, wireless communication device 700 provides aplatform for the storage, operation, and management of mobile widget 102for end user 104. For example, wireless communication device 700 mayinclude a widget management client (WMC) 704 that is executable toobtain one or more mobile widgets 102, such as from a widget managementsystem 300. Additionally, WMC 704 may be executable to supervise mobilewidget operation, and to track mobile widget activities on wirelesscommunication device 700 and report such activities to a widget trackingcomponent 1100.

Widget management system (WMS) 300 is operable to communicate with WMC704, for example via a wireless interface 106 and a message routercomponent 500, and includes one or more catalogs 302 of one or morewidgets 102 available for purchase and/or download to wirelesscommunication device 700. WMS 300 may include a digital locker 304operable to store records of each widget 102 downloaded to each device700, as well as the corresponding configuration of each widget 102 oneach device 700. A widget configuration may include settings relating toan appearance of widget 102, as well as an operation of widget 102,including one or more content update settings. In conjunction withproviding access to widget catalogs 302 and widgets 102, WMS 300optionally may include a widget recommender 306 to provide end user 104with advice, suggestions, or recommendations of mobile widgets 102 thatmay be of benefit or of interest to end user 104.

As noted, message router component 500 is operable to interface betweenWMC 704 and the widget-supplying and content-supplying components ofsystem 100. In particular, message router component 500 provides theinterface with WMS 300 and CAS 900 to exchange messages relating todownloading mobile widget 102, configuring mobile widget 102, updatingmobile widget content, scheduling of content updates, and reporting ofdata tracking the activity of or end user interaction with mobile widget102. As such, in some aspects, message router component 500 defines anetwork element that manages and controls all communications with WMC704.

Further, in some aspects, system 100 may include a widget managementportal 800 that allows end user 104 to access WMS 300 to inquire aboutavailable mobile widgets 102 and widget catalogs 302. Further, widgetmanagement portal 800 allows end user 104 to configure the functionalityand appearance of mobile widget 102 on wireless communication device700. As such, widget management portal 800 provides end user 104 withalternative interface for mobile widget management.

In system 100, WMS 300 may obtain mobile widget 102 and widget catalog302 from a unified widget manager (UWM) 200. UWM 200 provides acontrolled point-of-entry into system 100 for mobile widget 102. Inparticular, UWM 200 may be operable to insure that each mobile widget102 meets one or more predetermined architectural and/or operationalwidget standards for functioning within system 100. Additionally, UWM200 provides a common, virtual marketplace that enables one or moremobile widget developers/providers 108 to introduce their respectivemobile widget 102 to an operator 110, such as a wireless networkcarrier, of system 100. For example, widget developers/providers 108 maysubmit one or more mobile widgets 102 to UWM 200 via a developerinterface 202, and operator/carrier 110 may access and review mobilewidgets 102 at UWM 200 via an operator interface 204, where developerand operator interfaces 202 and 204 may be a network-accessibleinterface such as an extranet. Further, for example, via UWM 200, one ormore developers/providers 108 and one or more operators/carriers 110 mayaccess a widget virtual negotiation component 206, such as a widgetbidding exchange, where an agreement may be reached regarding one ormore of mobile widget pricing, mobile widget operation, mobile widgetcontent updating, mobile widget placement in widget catalogs, mobilewidget billing, developer/provider compensation, or operator/carriermobile widget cost in system 100.

Additionally, in some aspects, system 100 may have a backend system 101for analyzing the tracked data and transactions within system 100. Inparticular, backend system 101 may include an analytics component 1200that receives and examines the data of system 100, and a reportingcomponent 1300 that generates reports, including operator/carrierproprietary information 1302, based on the results of the analysis ofanalytics component 1200. Further, backend system 101 may include abilling component 1400 that accounts for transactions in system 100 anddebits and/or credits one or more end users 104, developers/providers108, operators/carriers 110, or advertisers 908. For example, end user104 may purchase and download mobile widget 102 to a respective wirelesscommunication device 700. This purchase transaction may be recorded byWMS 300 and reported to analytics component 1200, which extractsrelevant information for use by reporting component 1300 and/or billingcomponent 1400 to generate, respectively, an accounting of thetransaction and a bill or invoice corresponding to the transaction. Theaccounting and the billing may represent, for example, one or more of apurchase price/account receivable to be debited to an end user account,an operator/carrier account payable to be credited to anoperator/carrier account, a developer/provider account payable to becredited to a developer/provider account, or an advertiser accountreceivable to be debited to an advertiser account.

It should be noted that the components within and functionalitiesprovided by system 100 may be configured in any manner. For example, thevarious functionalities of any single system component alternately maybe performed by individual system components. As such, it should benoted that the aspects of system 100 may be rearranged in any of avariety of manners, and yet still achieve the stated functionality.

Further, it should be noted that the infrastructure components, e.g. thecomponents to the right of wireless interface 106 in FIG. 1, may becommunicatively coupled by one or any combination of wired or wirelesslinks, referred to as infrastructure communication network 112. As such,infrastructure communication network 112 may be a wired network, awireless network, or a combination wired/wireless network, for exampleincluding LANs, WANs, PSTNs, the Internet, circuit-switched and/orpacket-switched networks.

Thus, system 100 provides one aspect of an end-to-end system formanaging mobile widgets in a wireless network environment. Furtherdetails of the various system components and their aspects will now bediscussed.

Infrastructure Element/Network Device

In system 100, the network-side or infrastructure elements may includeone or more of any type of computer device, such as a network device,operable to perform the functionality described herein. In particular,the network-side or infrastructure elements that may include networkdevice include, but are not limited to, one or any combination of thefollowing system components: end user 104, developer/provider 108,operator/carrier 110, unified widget manager (UWM) 200, widget biddingexchange 230, widget management system (WMS) 300, digital locker 304,recommender 306, message router 500, content access server (CAS) 900,content provider 902, advertisement serving platform 1000, advertisementbidding exchange 1002, advertiser 1004, widget tracking component 1100,analytics component 1200, reporting component 1300, billing component1400 and, generally, backend system 101.

Referring to FIG. 4, in one aspect, such a computer device or networkdevice may be represented by network device 120, which is operable tocommunicate with any other network-side or infrastructure elements ofsystem 100 and/or with wireless communication device 700 (FIG. 1) and/orWMC 704 (FIG. 1). Network device 120 includes any type of network-basedcommunication device, such as a network server operable on acommunication network that links the components of system 100 (FIG. 1).For example, the communication network underlying system 100 (FIG. 1)may be a wired or wireless communication system, or a combination ofboth, and includes wireless interface 106, such as a wireless accessnetwork of operator/carrier 110 (FIG. 1) on which wireless communicationdevice 700 operates.

Network device 120 includes a processor component 122 for carrying outprocessing functions associated with one or more of components andfunctions described herein. Processor component 122 can include a singleprocessor, or multiple set of processors or multi-core processors.Moreover, processor component 122 can be implemented as an integratedprocessing system and/or a distributed processing system. In particular,processor component 122 is operable to execute a software program orapplication from memory in order to receive and process inputs andgenerate outputs corresponding to the functionality of the respectiveinfrastructure element as described herein.

Network device 120 further includes a memory 124, such as for storinglocal versions of software programs or applications, including scripts,codes, algorithms, heuristics, neural networks, rules, fuzzy logic, andexecutable instructions, being executed by processor component 122.Memory 124 can include one or more types of random access memory (RAM),read only memory (ROM), and a combination thereof.

Further, network device 120 includes a communications component 126 thatprovides for establishing and maintaining communications with one ormore other components utilizing hardware, software, and services asdescribed herein. Communications component 126 may carry communicationsbetween components on network device 120, as well as between networkdevice 120 and external devices, such as wireless communication device700 (FIG. 1), other network-side or infrastructure elements, or otherdevices serially or locally connected to network device 120.Communications component 120 includes a receiver to receivecommunications and a transmitter to transmit communications. Further,communications component 120 includes the corresponding receive chaincomponents and transmit chain components to enable exchanging messagesaccording to one or more respective protocols.

Additionally, network device 120 may further include database 128, whichcan be any suitable combination of hardware and/or software, thatprovides for mass storage of data/information, data relationships, andsoftware programs/applications employed in connection with aspectsdescribed herein.

Network device 120 may additionally include a user interface component130 operable to receive inputs from a user of network device 120, and togenerate outputs for presentation to the user. User interface component130 may include one or more input devices, including but not limited toa keyboard, a number pad, a mouse, a touch-sensitive display, anavigation key, a function key, a microphone, a voice recognitioncomponent, any other mechanism capable of receiving an input from auser, or any combination thereof. Further, user interface component 130may include one or more output devices, including but not limited to adisplay, a speaker, a haptic feedback mechanism, a printer, any othermechanism capable of presenting an output to a user, or any combinationthereof.

Thus, in one example, network device 120 includes hardware, or software,or combinations of hardware and software, operable to enable performingthe functionality of one or more of the network-side or infrastructureelements of system 100 (FIG. 1).

Unified Widget Manager

Referring to FIGS. 1 and 5, as discussed above, UWM 200 provides aclearinghouse for mobile widgets 102, which may be presented to system100 by developer/provider 108 via developer interface 202 and which maybe managed by operator/carrier 110 via operator/carrier interface 204.

Developer interface 202 provides an access point, such as an extranet,for developers/providers 108 to submit mobile widgets 102 to system 100.In some aspects, submitted mobile widgets 102 may be subject to avalidation process 210 executable by a widget validation component 212,resulting in a respective submitted widget 102 being either a trustedwidget or an untrusted widget or alternately being denied entry intosystem 100. Validation process 210 may be an automated process, a manualprocess, or a combination of both, that determines if submitted mobilewidget 102 conforms to one or more widget system standards 216 andperforms on system 100 as designed by developer/provider 108. If thesubmitted mobile widget 102 passes validation process 210, then therespective mobile widget 102 will be classified as a trusted widget. Insome aspects, trusted mobile widgets may have a trust indicator, such asa digital certificate corresponding to UWM 200 or widget validationcomponent 212 to indicate trustworthiness. If the submitted mobilewidget 102 either fails validation process 210 or enters system 100 inanother manner, such as via the public domain or from being directlydefined by a user, then the respective mobile widget 102 may byconsidered an untrusted widget.

In some aspect, developer/provider 108 may submit mobile widget 102 tosystem 100 in the form of an unvalidated widget package 216, whichrepresents a type of untrusted widget. Unvalidated widget package 216may include the relevant components that define the respective widget,including its operation on system 100 and its pricing. For example, inone aspect, unvalidated widget package 216 may include: a widgetidentifier 218 to identify or describe the widget, and/or to identifytargeted demographics or user behavioral categories to which the widgetmay be directed; widget application or code 220 comprising theinstructions, objects, etc. to allow the respective widget to operate ona given computer platform, such as different types of wirelesscommunication device 700 and/or on a personal computer (PC) usingdifferent technologies; a recommended update schedule 222 that defines arecommendation or suggestion of the developer/provider 108 of when thecontent represented by the widget should be updated—for example, thetemporal aspects of widgets may vary, as so some widgets such as a stockwatcher widget may preferably have frequent updates during market hoursand much less frequent updates after market hours, versus a weatherwidget which may preferably be updated only a few times per day; andproposed pricing 224 that defines one or more price-related and/ormarketing/selling-related aspects of the widget, such as one or more ofa desired end user price, developer/provider compensation or fee orroyalty, discounts, carrier-specific pricing, catalog placementconsiderations including catalog type and slotting position, etc. Uponpassing through validation process 210 and achieving widget systemstandard(s) 214 as defined by widget validation component 212, therespective unvalidated widget package 216 may be allowed into system 100as a validated widget package 226, which represents a type of trustedwidget.

Mobile widgets 102 accepted by UWM 200 may be accessed and modified byboth developer/provider 108 and operator/carrier 110 via a widgetvirtual negotiation component 206 that may be entered, for example, viadeveloper interface 202 and operator/carrier interface 204,respectively. Similar to developer interface 202, operator/carrierinterface 204 provides an access point, such as an extranet, foroperator/carrier 110 to interact with UWM 200. For example, one or moreoperators/carriers 110 may review mobile widgets 102, or in some aspectsvalidated widget packages 226, to determine if they want to include therespective widget in one or more widget catalogs 302 available to endusers 104 of system 100. Further, for example, widget virtualnegotiation component 206 allows developers/providers 108 andoperators/carriers 110 to negotiate various aspects of a respectivemobile widget 102, such as widget pricing, developer compensation,operator compensation, update scheduling, etc. In one aspect, forexample, widget virtual negotiation component 206 may include a widgetbidding exchange including auction functionality to control and reportthe results of an auction process used to define agreed upon parameterscorresponding to a respective mobile widget 102. In any case, in someaspects, after agreement between developers/providers 108 andoperators/carriers 110 on the final set of widget parameters, the mobilewidget 102 may be defined by a negotiated mobile widget package 228. Forexample, negotiated mobile widget package 228 may include: a widgetidentifier 230 to identify or describe the widget and/or to identifytargeted demographics or user behavioral categories to which the widgetmay be directed, which may be the same as identifier 218 or which may beoperator/carrier specific; widget application or code 232 comprising theinstructions, objects, etc. to allow the respective widget to operate ona given computer platform, which may be the same as widget applicationor code 220 or which may be operator/carrier specific; a negotiatedupdate schedule 234 that defines negotiated or initially acceptedcontent update schedule, which may be the same as recommended updateschedule 222 or which may be operator/carrier specific; and negotiatedpricing 236 that defines one or more price-related and/ormarketing/selling-related aspects of the widget as agreed upon duringthe negotiation, which may be the same as proposed pricing 224 or whichmay be operator/carrier-developer/provider specific or negotiationspecific.

Referring specifically to FIGS. 6 and 7, in one non-limiting example,one aspect of an architecture 240 and method 260 corresponding to widgetvirtual negotiation component 206 (FIGS. 1 and 5) include an onlineauction server 242 operable to interact with UWM 200 to perform auctionadministration duties and to transmit auction results. For example,online auction server 242 may be operable to present mobile widgetinventory to operators/carriers 110 (FIG. 1), as well as biddableparameters associated with each mobile widget, such as pricing andplacement (FIG. 7, action 262). For example, biddable parameterscorresponding to mobile widget placement may include, but are notlimited to, parameters such as slotting placement for position on awidget wall, a “featured” parameter corresponding to featuring therespective mobile widget in the display of a shopping mobile widget, andslotting placement for each category of widgets or for each widgetcatalog. Further, the mobile widgets presented by online auction server242 may have additional targeting metadata, such as the data of thetargeted demographics or user behavioral categories to which the widgetmay be directed. As such, operator/carrier 110 (FIG. 1) is able toaccess biddable items and enter bids corresponding thereto (FIG. 7,actions 264 and 266). Based on the auction results (FIG. 7, action 266),UWM 200 modifies the records of corresponding mobile widgets 102 and/ormobile widget catalogs 302 (FIG. 7, action 268), which are received byWMS 300 and updated in the corresponding records of digital locker 304(FIG. 7, action 270). Thus, as a result, such updated records are thenmade available to WMC 704 and widget management portal 800 to insure enduser 104 (FIG. 1) has access to the latest information.

Additionally, in some aspects, UWM 200 allows operator/carrier 110 toorganize one or more mobile widgets 102 into one or more widget catalogs302, for example, using a catalog manager component 240 accessible viaoperator/carrier interface 204. In one aspect, for example,operator/carrier 110 selects negotiated widget packages 228 forinclusion in one or more widget catalogs 302, which may be organized inmany different fashions, such as by widget functionality, etc. Further,for example, each widget catalog 302 includes a listing of mobilewidgets 102 that may be organized in a predetermined fashion, such asbased on payments for a given slotting placement, etc. Widget catalog302 may be defined by a catalog record that includes mobile widgetmetadata describing each mobile widget 102 and corresponding parametersthat may be of interest to a catalog viewer, such as one or anycombination of a name of the widget, a description of the widgetfunctionality, a graphic or visual representation of the widget, widgetpricing and purchasing information, etc. Further, for example, thelisting of mobile widgets 102 in widget catalogs 302 may be varied aftercreation of widget catalog 302, such as based on end user preferences,and/or end user behavioral information, and/or end user devicecapabilities. In any case, catalog manager component 240 further allowsoperator/carrier 110 to transmit widget catalogs 302 to WMS 300 so thatthe listed mobile widgets 102 may be made available to end users 104.

Further, UWM 200 may further include a widget manager component 242 thatallows operator/carrier 110 to change one or more parameters orcharacteristics of mobile widget 102. For example widget managercomponent 242 may allow operator/carrier 110 to: activate or deactivatea respective mobile widget 102 for operation on system 100; set orchange a widget identifier, such as identifier 230; set or change widgetapplication/code, such as application/code 232; set or change a widgetupdate schedule, such as update schedule 234; and/or set or changepricing information, such a pricing 236. In one aspect, for example,widget manager component 242 may further include an update schedulingmanager 244 to specifically allow interaction with and setting ofupdates schedules for one or a group of mobile widgets 102. For example,update scheduling manager 244 may include logic, algorithms, heuristics,fuzzy logic, neural networks, etc., operable to provide automated updateschedules for individual or groups of mobile widgets 102 or end users104, for example, that take into account and/or balance end userconsiderations, mobile widget characteristics such as temporal aspectsof content, and operator/carrier considerations.

Thus, UWM 200 provides an access point and interfacing functionality fordevelopers/providers 108 to submit mobile widgets 102 into system 100.Further, UWM 200 provides validation functionality to approve mobilewidgets 102 for operation within system 100. Additionally, UWM 200provides a clearinghouse or marketplace that allows developers/providers108 and operators/carriers 110 to negotiate and agree upon financial andoperational parameters of mobile widgets 102. Moreover, UWM 200 providesan access point and interfacing functionality for operators/carriers 110to manage widget catalogs 302 and the content and characteristics ofmobile widgets 102 within system 100.

Widget Management System

Referring to FIGS. 1 and 8, WMS 300 is an infrastructure element thatinteracts with UWM 200 to obtain mobile widgets 102, widget catalogs302, and widget modifications such as changes to widget operational orconfiguration parameters. Further, WMS 300 provides an end user-facinginterface that allows end user 104, via WMC 804 on wirelesscommunication device 700 and/or via widget management portal 800, toview, select, purchase/download, and configure mobile widgets 102.Additionally, WMS 300 provides management functionality for mobilewidget distribution to wireless communication devices, for storing andimplementing mobile widget configuration and subscription parameters,and for effecting, recording, and reporting on mobile widgettransactions.

In one aspect, for example, WMS 300 includes widget database 310 forstoring one or more widget catalogs 302 and/or one or more mobilewidgets 102. Further, WMS 300 may include a subscription managercomponent 312 that interacts with WMC 704 and/or widget managementportal 800 to allow end user 104 to access widget catalog 302 orindividual mobile widgets 102 for purchase and/or download onto wirelesscommunication device 700.

Further, subscription manager component 312 may be operable to controlone or a plurality of subscriber records 314 in a database such asdigital locker 304. Each subscriber record 314 includes information oneach end user and on each mobile widget 102 corresponding to each enduser to enable the management and control of mobile widgets forsubscribers. For example, in one aspect, subscriber record 314 mayinclude one or any combination of: a subscriber identifier 316, such asa name, subscriber number, phone number, wireless device serial number,etc. that may be used to uniquely identify a given end user 104 and/orwireless communication device 700; subscription information 318including a subscription identifier, a subscription description, asubscription key, a license, a validity time period, a service level,and any other information relevant to enabling operation of a mobilewidget on a wireless device—such subscription information 318 mayauthorize end user 104 and/or wireless communication device 700 toreceive or operate an individual or a class of mobile widgets, and mayfurther authorize or identify a service level that may allow one of anumber of levels of service corresponding to a mobile widget, whereinsuch service levels may regulate a number or volume of content updates,message exchanges, etc. performed by the respective mobile widget;mobile widget identifier(s) 320 to identifier one or more mobile widgets102 purchased/downloaded to wireless communication device 700 and/or WMC704 and authorized for operation; mobile widget configuration data 322,corresponding to each mobile widget identifier 320, that defines howcorresponding mobile widget 102 is presented and/or operates, which mayinclude user-defined/customized configuration data entered by end userto personalize the respective mobile widget according to userpreferences; a transaction history 324 that includes transaction detailsrelating to end user 104 accessing, purchasing/downloading, andconfiguring a respective mobile widget 102; and a subscriber profile 326that includes information that describes end user 104, definesdemographic information of end user 104, and/or defines behavioralinformation of end user 104, wherein such information may be utilizedfor marketing purposes, such as to recommend mobile widgets to end user104 and/or to provide advertising to end user 104. Thus, WMS 300 storesand controls the relationships between each mobile widget 102 and eachsubscriber or end user 104 in system 100 through digital locker 302.

Optionally, WMS 300 may include recommender component 306 operable tointeract with subscription manager component 312, digital locker 304,widget database 310, other infrastructure elements such as UWM 200 orCAS 900 to obtain widget slotting information or widgetadvertising-related information and other external entities, such asproviders of marketing and/or sales data, to suggest mobile widgets 102that may be of interest to subscriber/end user 104. For example, in oneaspect, recommender component 306 may include a data collector module330 operable to perform one or any combination of: gathering data aboutavailable mobile widgets, such as mobile widget metadata; gathering dataabout subscriber/end user, such as subscription information 318,transaction history 324 and subscriber profile information 326; orgathering other internal or external information relating to widgetpopularity, widget profitability, widget sales, widget advertising,widget positioning/slotting, widget marketing, etc. Further, recommendercomponent 306 may include an analyzer module 332 operable to execute oneor more algorithms, heuristics, fuzzy logic, etc. in order to determinepotential matches between one or more of the available mobile widgets orcatalogs, the available subscriber/end user data, and/or externalwidget-related information. Additionally, based on the results ofanalyzer module 332, recommender component 306 may further include arecommender module 334 operable to generate a message includingreferences to or links to or identification of one or more mobilewidgets 102 or widget catalogs 302 that may be of interest to thesubscriber/end user 104 and/or that may be of an economic interest ofoperator/carrier 110 to promote to subscriber/end user 104. Thus,recommender component 306 is operable to dynamically suggest orrecommend mobile widgets 102 or widget catalogs 302 to subscribers/endusers 104 based on any number of configurable parameters.

Further, in some aspects, WMS 300 may additionally include a billingreporter component 340 that keeps track of end user 104 interactionswith WMS 300 in downloading/purchasing of mobile widgets 102 and reportssuch activity to backend system 101 for accounting and billing purposes.For example, billing reporter component 340 may include a transactioncollector module 342 operable to interact with subscription managercomponent 312 and/or digital locker 304 in order to gather transactiondata relating to the download or purchase of mobile widgets 102 bysubscribers/end users 104. Further, a reporter module 344 is operable tointeract with transaction collector module 342 and generate a messagefor transmission to backend system 101 documenting the collectedtransactions, including the transaction details identifying aspects ofthe corresponding subscriber information, mobile widget metadata and thetransaction-specific data such as purchase price. Thus, billing reportercomponent 340 is operable to update backend system with billing-relatedinformation.

Message Router

Referring to FIGS. 1 and 9, in one aspect, system 100 includes a networkelement, such as message router (MR) 500, which provides a communicationinterface between the network infrastructure, such as WMS 300 and CAS900, and wireless communication device 700 and/or WMC 704. Inparticular, in one aspect, message router 500 communicates directly withWMC 704 by sending and/or receiving over-the-air (OTA) messages viawireless interface 106, and further relays those messages to WMS 300and/or CAS 900 via one or more infrastructure communications networks.

It should be noted that wireless interface 106 between message router500 and WTC 704 may have a different transport protocol than the one ormore infrastructure networks connecting message router 500, WMS 300 andCAS 900. As such, in some aspects, message router 500 may include aprotocol translator component 502 to enable message router 500 toexchange messages between device or transport mediums operating withdifferent protocols. For example, protocol translator component 502 mayinclude a translator module 504 having translation logic operable toaccess a translation database 506 in order to convert a message from oneprotocol to another protocol. For example, translator module 504 isoperable to translate a WMC-MR protocol message 508, for example a WMCoriginated message transmitted according to the protocol of wirelessinterface 106, into an MR-infrastructure message 510, for example amessage transmitted according to the protocol of the correspondinginfrastructure communication network 112. Similarly, for example,translator module 504 is operable to translate a infrastructure-MRprotocol message 512, for example an infrastructure originated messagetransmitted according to the protocol of the correspondinginfrastructure communication network 112, into an MR-WMC message 514,for example a message transmitted according to the protocol of wirelessinterface 106. In performing such message translation, translator module504 is operable to access a local or remote translation database 506that stores relationships and data corresponding to an originatingdevice/interface 516, a destination device/interface 518, andcommunication protocols 520. For example, using translation database506, translator module 504 is able to identify or determine thecorresponding protocol used for a message received from a respectiveoriginating device or transported over a corresponding originatinginterface, as defined by the data of originating device/interface 516.Similarly, for example, using translation database 506, translatormodule 504 is able to determine the corresponding protocol to use for amessage destined for a respective destination device or to betransported over a corresponding destination interface, as defined bythe data of destination device/interface 518. It should be noted thatoriginating device/interface 516 and destination device/interface 518may be combined, for example, to provide relationships between devicesand/or interfaces and corresponding protocols 520.

In any case, message router 500 is operable to transport messages in anydesired protocol. For example, such protocols can include hypertexttransfer protocol (HTTP), an Internet Protocol (IP) socket protocol, ashort message service (SMS) protocol, and any wired and/or wirelessnetwork protocols, such as code division multiple access (CDMA)-basedprotocols and global system for mobile communications (GSM)-basedprotocols.

Wireless Interface

Referring to FIG. 1, wireless interface 106 may be any one or anycombination of a variety of wireless communication systems. Such systemsoften employ different spectrum bandwidths and/or different airinterface technologies. Exemplary systems include one or any combinationof the wireless systems discussed above.

Infrastructure Communication Network

Referring to FIG. 1, infrastructure communication network 112 may be anyone or any combination of a variety of wired or wireless communicationsystems, or a combination of both. Exemplary systems include one or anycombination of the wired or wireless systems discussed above.

Wireless Communication Device and Widget-Related Components

FIG. 10 represents a high-level block diagram of a wireless device 700operable to store, present, and manage mobile widgets 102. As previouslynoted, the wireless device may include any device capable of operatingon a wireless communication system. For example, wireless device 700 maybe embodied as a cellular telephone, a cordless telephone, a SessionInitiation Protocol (SIP) phone, a wireless local loop (WLL) station, apersonal digital assistant (PDA), a handheld device having wirelessconnection capability, or other processing device connected to awireless modem. The wireless communication system may any of variety ofsystems, which often employ different spectrum bandwidths and/ordifferent air interface technologies. Exemplary systems include CDMA(CDMA 2000, EV DO, WCDMA), OFDM, or OFDMA (Flash-OFDM, 802.20, WiMAX),FDMA/TDMA (GSM) systems using FDD or TDD licensed spectrums,peer-to-peer (e.g., mobile-to-mobile, etc.) ad hoc network systems oftenusing unpaired unlicensed spectrums, and 802.xx wireless LAN orBLUETOOTH techniques.

The wireless device 700 includes a memory 706 and a processor 708 thatis in communication with memory 706. Processor 708 is operable forcarrying out processing functions associated with one or more ofcomponents and functions described herein. Processor 708 can include asingle or multiple set of processors or multi-core processors. Moreover,processor 708 can be implemented as an integrated processing systemand/or a distributed processing system. Memory 706 is operable forstoring applications being executed by processor 708, such as mobilewidgets 102. Memory 706 can include random access memory (RAM), readonly memory (ROM), and a combination thereof.

Additionally, wireless device 700 includes user interface 702 operableto receive inputs from a user of wireless device 700, and to generateoutputs for presentation to the user. Thus, user interface 702 mayinclude one or more input devices, including but not limited to akeyboard, a number pad, a mouse, a touch-sensitive display, a navigationkey, a function key, a microphone, a voice recognition component, anyother mechanism capable of receiving an input from a user, or anycombination thereof. Further, user interface 702 may include one or moreoutput devices, including but not limited to a display, a speaker, ahaptic feedback mechanism, a printer, any other mechanism capable ofpresenting an output to a user, or any combination thereof. In aspectsherein disclosed user interface 702 may include a display operable toprovide a visual presentation of widgets 102, a touch sensitive displayoperable to provide a visual presentation and receive inputs to thewidgets 102 and/or a keypad to receive inputs to the widgets 102 or thelike.

Memory 708 can store one, two, or a plurality of mobile widgets 102. Aspreviously noted mobile widgets 102 are applications executable on thewireless device 700 that provide specific functionality, such as contentdelivery, to the user via a specialized user interface 702, such as avisual display. In some instances, mobile widgets 102 may provide theuser access to web/Internet-based content that is delivered over thewireless network. In other instances, the mobile widgets 102 may providefor access to content that is device-based, such as, for example,current battery status, current location, or the like.

Additionally, memory 708 can store a Widget Management Client (WMC) 704that includes a corresponding widget manager 710 for each mobile widgetapplication 102 stored in the memory 708. WMC 704 is executable towirelessly obtain one or more mobile widgets 102, from the wirelesscommunication network and supervise mobile widget operation.Additionally, WMC 704 and, specifically widget managers 710, may beexecutable to track mobile widget activities on wireless communicationdevice 700, report such activities to a network component, such as awidget tracking component 1100. Also, the widget managers 710 mayprovide management over the schedule for updating content and managementcover the configuration of the presentation of the content on the userinterface 702.

FIG. 11 provides a more detailed block diagram representation of theWidget Management Client (WMC) 704, which is stored on the wirelesscommunication device 700. The WMC includes one or more widget managers710 each corresponding to a mobile widget 102 stored on the wirelessdevice 700. The illustrated aspect of FIG. 11 depicts widget managers,710-A, 710-B and 710-N, where N represents the last widget manger 710from among the plurality of widget managers.

Widget manager 710 includes a content update scheduler 712 that includeslogic that is operable to be update the schedule for content deliverybased on one or more preconfigured content delivery attributes. Contentdelivery attributes may include, but are not limited to, widget usage,time of day/week/month/year, user/device location or the like. Forexample, widget usage may dictate that more frequently accessed widgets(e.g., widgets that are clicked-on or the like) are provided morefrequent content updates while less accessed widgets are provided lessfrequent content updates. In another example, the logic may determinewhat time of day a user is most likely to access a widget and in turn,schedule more frequent content updates during that time. Additionally,the logic may associate location with content updates, such that whenthe user/device is the vicinity of a specified location, more or lessfrequent updates occur. For example, if a user is within the vicinity ofa sports stadium, the logic may be configured to provide more frequentupdates for a sports information-related widget.

It should be noted that while the content update scheduler 712 provideslogic to determine update schedules based on one or more contentdelivery attributes; the schedule can also be based on networkpreferences/factors for content delivery and/or user configuration ofcontent schedules. Therefore, the content update schedule 712 mayadditionally include logic that provides for prioritizing, weighting, orotherwise factoring content delivery based on the content deliveryattributes, the network preferences/factors, and/or the userconfiguration. Additionally each widget manager 710 may be configuredsuch that the user may override the content update scheduler 712 andeither provide for their own content update schedule via an option inthe widget management module 722 of the widget wizard 718. Additionallythe widget may be configured through the widget management module 722 ofthe widget wizard 718 with a button or other user interface that allowsfor the user to instantaneously request a content update.

Widget manager 710 also includes widget usage reporter 714 that includeslogic operable for collecting and reporting widget usage information.FIG. 12 provides a more detailed block diagram of the widget usagereporter 714. The reporter 714 may include usage data collector 740operable to collect widget usage data 742. The widget usage data mayinclude, but is not limited to, such as widget access frequency, thedepth of the access (i.e., how many click-throughs the widget undergoesduring an access), the time of day/week that the widget is accessed andthe like. The usage reporter 714 may additionally usage data storage 744or optionally the widget usage data 742 may be stored in another datastorage component external from the widget usage reporter 714 or thewidget management client 704. The usage reporter 714 may additionallyinclude a usage data report compiler 746 operable for compiling rawusage data into one or more usage data reports 748 based on networkoperator, widget developer and/or third party report criteria.Alternatively, in other aspects, the widget usage reporter maycommunicate raw widget usage data 742 to the network.

The collected widget usage information, either raw widget usage data 742or compiled usage reports 748, to network entities. For example, thewidget usage data 742 may be communicated to a network entity, such asdigital locker 304 of Widget Management System (WMS) 300 (FIGS. 1 and8). The WMS may implement the usage data 742 to determine content updateschedules for the widget, to prioritize widgets in the user's personalwidget catalog or the like. Additionally, the WMS 300 may communicatethe usage information to a backend system 101 (FIG. 1) for reportingpurposes and/or billing purposes.

Referring again to FIG. 11, widget manager 710 additionally includeswidget-specific renderer 716 that includes logic operable for presentingthe widget 102 on the wireless device 700 based on one or more renderingattributes. Rendering attributes widget usage, time ofday/week/month/year, user/device location or the like. For example,widget usage may dictate that more frequently accessed widgets (e.g.,widgets that are clicked-on or the like) are provided on the initialwall of the user interface or in a prominent position on the userinterface. In another example, the logic may determine that the date isa Sunday during the fall season and therefore a football score reportingwidget may be provided on the initial wall of the user interface or in aprominent position on the user interface. It should be noted that whilethe widget-specific renderer 716 provides logic to determine where awidget should be rendered on a display the renderer 716 may also providefor user configuration of rendering rules that may override or augmentthe rendering decision made by the logic.

The WMC 704 additionally includes a widget user interface, such aswidget wizard 718, operable to provide the user with an interface tomanage which widgets 102 are stored and presented on the wireless device700, as well as an interface to purchase or otherwise obtain widgetsfrom a marketplace. In addition to a wireless device-based userinterface, such as the widget wizard 718, the system 100 may include anetwork-based user widget management portal 800 (FIG. 1), which providesfor the device user to access the network from another wired or wirelessdevice, such as a PC or the like, to make changes to the configurationsettings, purchase/obtain additional widgets or otherwise manage thewidgets presented on the wireless device.

The widget wizard 718 may include widget management module 720 operableto provide the user with management over the widgets that are displayedon the user interface 702. In addition, the widget wizard 718 mayinclude widget catalog 722 operable to provide a user a current listingof the widgets currently available from the network operator or someother network source. FIG. 13 provides a detailed block diagram ofvarious components of the widget wizard 718 including widget managementmodule 720 and widget catalog 722. The widget management module mayprovide for a widget listing 750 that provides for the display of alisting of widgets 102 currently stored on the wireless device. Thelisting 750 provides for the user to instantaneously update the userinterface with selected widgets. In this regard, a user caninstantaneously deactivate a widget currently being presented/displayedand replace the widget with another widget stored on the device. Inaddition, the widget management module 720 provides for widgetconfiguration module 752 that is operable to provide for the user toconfigure the widgets based on personal preferences. The widgetconfiguration module 752 may include content update scheduleconfiguration 754 operable to allow the user to define the frequency bywhich each widget is provided content updates and content renderingconfiguration 756 operable to provide the user with the ability todefine the manner in which widgets are rendered/presented on the userinterface, such as the position on the display, the size of the widgetor the like. Upon user changes to the configuration settings inconfiguration module 752, the widget wizard 718 may upload or otherwisecommunicate the configuration changes to the network for storage in thedigital locker 304 associated with the user 104 and/or the wirelessdevice 700.

The widget wizard may additionally include widget catalog 722 thatprovides a widget listing 758 of widgets currently available from thenetwork source. The listing of widgets in the catalog may beperiodically updated, based on a set schedule or a user input, to insurethe currency of the widgets available to the user. The update or initialreceipt of the catalog may be provided by the WMS 300. In addition, thelisting 758 may be customized for the user based on previous widgetusage patterns or other attributes, such as time, location or the like.

In certain aspects, advertising widgets may be presented to the clientas an option via the widget catalog 722. In some aspects, advertisementwidgets may be offered to the user as a means of subsidizing orotherwise replacing the cost of other widgets. It should be noted thatif widget management client 704 is configured to provide for thepresentation of advertising widgets, the advertising widgets may be“locked” widgets, which do otherwise allow the user to manage orconfigure the widgets through the widget wizard 718. By locking theadvertising widgets the network operator and/or advertiser is assuredthat the advertisements are being displayed/presented without the userotherwise choosing to opt-out of the advertising widgets. Additionally,in those aspects that provide for advertising widgets the widget usagereporter 714 may be configured to provide specific collection andreporting of usage data related to the interaction that a user mayexperience with an advertisement, such as time viewed or the accesseddepth of the advertisement.

Referring again to FIG. 11, the WMC 704 additionally includes updatecontroller 724 and update adapter 726. The update controller 724 isoperable to control upstream and downstream data delivery to and fromWMC 704. For example, the update controller 724 may be operable tocontrol the delivery of usage data 742 or usage data reports 748 tonetwork entities, widget configuration settings, and/or user requests topurchase/obtain a new or updated widget. In certain aspects, the updatecontroller 724 may be operable to collate and provide data to networkentities, such as the Widget Management System (WMS) 300. In addition,update controller 724 may be operable to receive widget content updates,updates to the widget catalog 722, configuration settings for contentupdate schedules, content reporting requests or the like.

Further, the update adapter 726 is operable to handle the upstream anddownstream transport of the data from the WMC 704 to the appropriatenetwork entity. In this regard the update adapter 726 is operable toreceive/transmit data over a specified type of network connection, forexample, an Internet Protocol (IP) socket, a HyperText Transfer Protocol(HTTP) socket, Short Messaging Service (SMS), or the like. Additionally,the update adapter 726 is operable to compare the existing configurationof widgets with WMS-pushed configurations and make changes to theconfigurations accordingly; such as instantiating new widgets and/ordisabling deactivated widgets.

The WMC 704 may additionally include a throughput sensor 728 operablefor sensing the throughput time and estimating the time to downloadcontent update for a widget. The throughput sensor 728 is operable to beengaged upon opening WMC 704, and approximate throughput time can besensed by establishing an IP connection and measuring the Round TripTime (RTT). Based on the approximate throughput time and the size of theprevious content update for a widget of interest, an estimate can beestablished of the time to update a widget and provided to the user whenthe user requests an update. In addition, the throughput sensor 728 maybe configured to provide for a user warning if the content update willtake more than a predetermined threshold of time.

The WMC 704 may additionally include subscriber ID/credential determiner730 operable to determine the subscriber/user identification associatedwith the WMC 704. In one aspect, the subscriber ID determiner 730 mayinitiate a HTTP call and the response header may include the subscriberidentification. In alternate aspects, the subscriber ID determiner maybe derived from the wireless device or the like. Additionally, thesubscriber ID/credential determiner 730 may be configured to determinesubscriber/user credentials by prompting the user to enter theappropriate credentials, e.g. user id. Based on the input, the usercredentials are compared to the subscriber identification and if a matchis determined, a report acknowledging the match may be communicated tothe WMS 300 and a record created in the digital locker 304 associatedwith the subscriber/user. Subsequently the subscriber ID and thesubscriber credentials may be included in all messages communicated fromthe WMC 704 to the message router 500.

As previously noted, in addition to configuring the widget managementclient (WMC) 704 and associated mobile widgets 102 on the wirelessdevice, the system provides for a user widget management portal 800, asshown in FIG. 16. The user widget management portal 800 allows for theuser 104 to access the component via another device, such as a wired PCor another wireless device, to manage the (WMC) on the wireless device700. The user widget management portal 800 is in network communicationwith the widget management system (WMS) 300 and WMS 300 is in wirelesscommunication with the wireless device 700 via message router 500. Theuser widget management portal 800 acts as complement to the widgetwizard 718 on the wireless device 700 by providing user 104 remoteaccess to the management of widgets on the wireless device. The userwidget management portal 800 is operable to receive informationpertaining to a user's current WMC 704 or widget 102 configurations fromthe user's profile stored in the digital locker 304 of WMS 300. As such,user widget management portal 800 may include a WMC configuration module810 operable to provide user 104 with the ability to re-configuresettings that apply to the overall WMC 704 in general. In addition, theuser widget management portal 800 may include one or more widgetconfiguration modules 820 operable to provide user 104 with the abilityto reconfigure the widgets 102 currently stored on wireless device 700.

In addition to WMC and widget configuration, the user widget managementportal 800 may provide for the user to learn about and/or acquire newwidgets. As such, user widget management portal 800 may include widgetcatalog 302 as communicated from widget management system 300. Inaddition, the widget catalog 302 may be personalized for user 104 suchthat widgets of interest to user 104 are listed in the catalog near thebeginning or are otherwise highlighted. Widgets of interest may beidentified by the WMS 300 based on widget usage tracking/metering datacommunicated from the wireless device 700. Once a user selects, acquiresor otherwise purchases a new widget, the user management portal 800communicates the selection to the WMS 300 and the WMS 300 subsequentlyretries the widget from a corresponding content access server 900 (FIG.17) and communicates the widget to the wireless device via messagerouter 500.

Content Access Server/Content-Advertising-Tracking Components

Referring to FIG. 17, a detailed block diagram highlighting the contentaccess server 900 is depicted. Content access server 900 is operable toprovide content to the mobile widgets 102 based on a predeterminedupdate schedule for the widget. As previously mentioned the updateschedule may be logically determined based on one or more contentdelivery attributes, network attributes and/or user configurationsettings. A mobile widget 102 will initiate a content request 904 basedon the update schedule, which is wirelessly received by the contentaccess server 900 via the message router 500. The content access server900 will act on the request 904 by retrieving current content fromcontent provider 902 or, in the case of advertisements serving platform1000, which is in communication with an advertisement source. Once thecontent update is retrieved, the update is communicated to the wirelessdevice for presentation on the corresponding widget. For example, if themobile widget is a sporting event score reporting widget, a request maybe sent to the content access server and the content access server matretrieve a content update, in the form of updated sporting event scoresfrom a content provider 902, such as a web-based sports news site or thelike. In one aspect, the content access server 900 may include a contentpackage bundler 910 operable to bundle updates in a content updatepackage, such as a /zip file or some other spectrally efficientcompression mechanism. Bundling content updates in packages provides forsmaller messages that can be more efficiently delivered to the wirelessdevices. Content updates can be communicated to the wireless deviceacross different connections depending on the connections available atthe wireless device. Examples of connections include, but are notlimited, HTTP socket, IP socket, SMS, and the like.

In addition to providing content updates, content access server 900 mayserve as the receiving point for metering/tracking data communicatedfrom the WMC 704. In some aspects, the content update request 904 mayinclude the metering/tracking data, such as widget usage data 742 orwidget usage reports 748. In such aspects, the content access server 900includes a metering/tracking component 1100 operable to parse the widgetusage data 742 or widget usage reports 748 from the request and routethe metering/tracking data to a content provider 902 or the advertisingserving platform 1000. In addition, the content access server maycommunicate the metering/tracking data to a backend system 101, whichincludes an analytics component 1200 operable for receiving themetering/tracking data and logically determining usage patterns or thelike. The analytical data may be subsequently communicated and used bythe reporting component 1300 to generate predetermined reports and bythe billing component 1400 to generate widget bills, such as widgetbilling based on widget usage rates.

As previously noted, one or more widgets that are stored and presentedon the wireless device 700 may include advertising widgets operable todisplay advertisements in widget form. In certain aspects, advertisingwidgets may be provided by the widget operator as an opt-in feature, inwhich the user is offered the option of opting to accept advertisingwidgets in lieu of some form of compensation, such as a reduction in thecost of other non-advertising widgets or the like. Thus, advertisementwidgets may be configured be the widget providers in conjunction withthe advertisers as a “locked” widget, meaning that the user is unable tore-configure the widget or otherwise deactivate the widget on thewireless device. FIG. 14 provides a block diagram of an example of awidget advertisement 1010 and, more specifically, the advertisementmetadata 1012 included in such advertisements. The metadata 1012 mayinclude an advertisement identifier 1014, such as id number that servesto identify the advertisement, and a resource location identifier 1016that serves to identify the source of the advertisement, such as an IPaddress or the like. The metadata 1012 may additionally includeassociated interaction 1018, which serves to define user interactionswith the advertisement, such as click-to-browse functionality or thelike and/or landing location 1020, which defines a URL location for userinteraction other than click-to-browse. In other aspects, the metadata1012 may include the TTL (Time to Live) 1022 for the Advertisement,which defines the expiration date for the advertisement on the wirelessdevice, and time/frequency of display metrics 1024, which definespecific times and/or the frequency by which the advertisement should bedisplayed on the wireless device. Additionally, the metadata 1102 mayinclude contextual display metrics 1026, which define other contextparameters related to the display of the advertisement and wirelessdevice metric collection instructions 1028, which define the metricsthat are to be collected at the wireless device, and subsequentlycommunicated to the network, in relation to the display of theadvertisements, such as time/frequency of display, frequency of userinteraction with the advertisements, depth of click-throughs and thelike. The metadata 1012 may additionally any other metadata 1012 relatedto the advertisement 1010, the display of the advertisement on thewidget or the reporting functions.

As shown in the block diagram of FIG. 15, advertisements 1010 arewirelessly communicated to the advertising widget 102-1 on the wirelessdevice 700 via an advertising source, such as advertising servingcomponent/platform 1000. The advertising serving platform 1000 is incommunication with content access server 900, such that advertisements1010 are communicated from the advertising serving platform 1000 to thewireless device 700 through the content access server 900. Additionally,the message router 500 is in communication with the content accessserver 900 and serves to insure that the advertisements and relatedinformation are communicated to and from the wireless device via thewireless network 106 using a unified communication protocol. Theadvertising serving platform is in communication with an advertisementdatabase 1040 that stores the inventory of advertisements 1110. Thus,the advertising serving platform is operable to retrieve advertisements1110 from the database 1020 and communicate the advertisements to theadvertising widget 102-1 on the wireless device.

In addition, similar to a content update request as described above,wireless device may issue an advertisement request 1040 operable torequest delivery of an advertisement for presentation of anadvertisement on the wireless device. The advertisement request isreceived by the advertising serving platform 1000, which obtains anadvertisement from advertisement database 1040. The advertisementrequest may include, an identifier, issued by the advertising servingplatform 1000, which identifies the WMC 704. The request mayadditionally include a metering/tracking report that identifiesadvertisements recently presented and the number of presentations duringthe TTL.

Additionally, the advertising serving platform 1000 may further comprisean ad campaign manager 1050 operable to manage advertising campaigns foradvertisers by communicating advertisements to advertising widgets basedon advertising campaign criteria. Advertising campaign criteria maydictate that certain advertisements are pushed to wireless deviceshaving expiration dates and frequency of display rates related to theadvertising campaign. In other aspects, the advertising campaign maytarget certain demographic information related to users, or certainwireless devices, such that certain advertisements are targeted forusers and/or wireless devices that are within the target audienceconfines. Demographic information may include, but is not limited to,user gender, user interests, user income, user age, user address,current used/wireless device location, and the like.

The advertising serving platform 1000 may additionally include atracking/metering component 1060 that tracks and meters informationrelated to the display of the advertisements on users advertisingwidgets. The tracking/metering component 1100 may parse out thosemetering and tracking data related specifically to advertisements 1010and advertising widgets 102-1 and communicate the advertising relatedmetering and tracking information to the tracking/metering component1060 of the advertising serving platform 1000. The tracking/meteringdata that is communicated from the WMC 704 may include advertisementidentifiers, number of presentations/displays on the advertising widget,depth of user interaction (e.g. number of click-throughs), elapsed timeof user interaction/viewing of advertisement and the like.

The advertising serving platform 1000 may additionally be incommunication with an advertising bidding exchange server 1002 that isoperable to allow for an advertising bidding marketplace to occurbetween advertisers 1004 and network/widget operators 110. The biddingexchange marketplace may provide for the advertisers 1004 to bid onwidget advertising based one or more advertising criteria, such as aposition/placement of the advertisement on the widget wall, thefrequency of presentation, the time of presentation, the demographics ofthe target audience and the like. In addition, the bidding exchangemarketplace may provide for the advertisers to bid based on broadcastand/or multicast presentation of advertisements in the widget. In oneaspect, the bidding exchange marketplace is a publicly availablemarketplace, such as an Internet-based marketplace that allows for alladvertisers or potential advertisers to bid on widget-based advertising.

Backend System

Referring back to FIG. 1, as previously noted, in some aspects, system100 may have a backend system 101 for analyzing the tracked data andtransactions within system 100. Backend system 101 may include one orany combination of analytics component 1200, reporting component 1300,and billing component 1400.

Analytics component 1200 receives and examines the data of system 100.

Reporting component 1300 generates reports, including operator/carrierproprietary information 1302, based on the results of the analysis ofanalytics component 1200.

Billing component 1400 accounts for transactions in system 100 anddebits and/or credits one or more end users 104, developers/providers108, operators/carriers 110, or advertisers 908.

Sample Call Flows

Referring to FIGS. 18-23, according to some aspects, some non-limitingexamples of call or messages flows are listed for various scenarios.Referring to FIG. 18, for example in one aspect, a high level call flowrelates to a widget management portal (WMP)-originated selection andconfiguration of a new mobile widget. In particular, WMP interacts withWMS to select and configure the mobile widget. The WMS interacts withCAS to obtain the content for the mobile widget. Additionally, the WMSforwards the mobile widget and/or the content update for the mobilewidget to the WMC via the message router.

Referring to FIG. 19, for example in one aspect, a high level call flowrelates to a WMC-originated selection, configuration and updating of amobile widget. In particular, WMC interacts with WMS to select andconfigure the mobile widget. The WMS interacts with CAS to obtain thecontent for the mobile widget. Further, the WMC may request a contentupdate for the mobile widget from the CAS, which responds with theupdated content, which the WMC confirms receiving.

Referring to FIG. 20, for example, in one aspect, a high level call flowrelates to a WMC accessing a web storefront in the WMS, wherein theoperator/carrier authorizes the access. In particular, the WMC requestsaccess to the storefront from the WMS, which verifies with theoperator/carrier that WMC is authorized for such access. For example,the verification may include passing an identifier or a credentialassociated with the WMC or the end user to a content management serveror authorization server of the operator/carrier to determine if WMC isauthorized. Upon receiving an authorization, WMS is then able to provideWMC with access to the storefront and allows subsequent interaction fordownloading of mobile widgets.

Referring to FIG. 21, for example in one aspect, a high level call flowrelates to a content update requested by a WMC. In particular, based onthe occurrence of a content update event, WMC sends a content updaterequest via the message router to the CAS. The CAS bundles thecorresponding content update and transmit it to the WMC via the messagerouter. It should be noted that rather than in one example, the contentupdate request may be user initiated. Additionally, it should also benoted that WMC may package metering/tracking data along with the contentupdate request. In this case, CAS is operable to route themetering/tracking data to other infrastructure elements, such as theanalytics component of backend system and/or the advertisement servingplatform.

Referring to FIG. 22, for example in one aspect, a high level call flowrelates to a reporting of widget metering/tracking data and acorresponding adjustment of a widget update schedule based on thereported metering/tracking data. In particular, WMC transmits a widgetmessage that includes metering/tracking data to CAS via message router.CAS is operable to route the metering/tracking data to otherinfrastructure elements, such as the analytics and reporting componentsin this case. The analytics and reporting components then determineusage data based on the reported metering/tracking data, which isprovided as an input to the WMS and/or the UWM for use in determiningcontent update schedules. Based on the usage data, a new update scheduleis determined for one or more users, and/or for one or more mobilewidgets. The new update schedule is stored at the WMS and/or the UWM,and is further communicated to the WMC via the message router. Thus, anew update schedule is effected based on an analysis of the reportedmetering/tracking data provided by WMC.

Referring to FIG. 23, for example in one aspect, a high level call flowrelates to the CAS providing WMC with a content update. In particular,CAS transmits a content request to a content provider, who responds witha content document. The content document may include various updatedcontent, as well as references to resources for further content updates.The CAS parses the content document and, if necessary, requests theadditional resources from the content provider. Upon receiving therequested resources, the CAS transforms the resources and the othercontent from the content document into an update package for delivery toWMC. Upon completing the transformation, the CAS forwards the contentupdate packet to the WMC via the message router.

Update Scheduling Optimization

Referring to FIGS. 24-26, in one aspect, apparatus and methods foroptimizing content updates for a mobile widget are provided. In using amobile widget as an alternative to a web browser, the mobile widget canbe pre-configured with a content update schedule to take into accountvarious scheduling factors. Further, in contrast to a PC-based widget,the content update schedule of the mobile widget can contemplate variousscheduling factors unique to the wireless network environment.

Referring to FIG. 24, in one aspect, update scheduling manager 244 ofUWM 200 (FIGS. 1 and 5) includes a scheduling module 246 having logic,algorithms, fuzzy logic, heuristics, or neural networks, etc. operableto generate a content update schedule 248 based on one or anycombination of scheduling factors 250. For example, scheduling factors250 may include, but are not limited to, one or any combination of:operator-related considerations 252, such as historical or projectedtemporal network usage or capacity data; end user-related considerations254, such as a user content update preference, user update patternhistorical data that defines how often an end user updates mobile widgetcontent and/or to what widget depth an end user views mobile widgetcontent, or how often a user updates respective widgets and thusidentifying a update priority among the respective widgets; content type256 corresponding to the content or to the mobile widget, such as howoften the content changes for the respective mobile widget; context 258of the mobile widget and/or the wireless communication device operatingthe mobile widget, such as an operational context comprises at least oneof a time or a geographic location; and device capability 260 of thewireless communication device operating the mobile widget, such asdisplay size, graphics rendering capabilities, processor speed,available memory size, etc.

For example, in one aspect, an operator-related consideration 252 maydefine one or more time periods when the cellular network usage is high,and scheduling module 246 may develop content update schedule 248 toavoid or minimize content updates during those time periods.

In another example, in one aspect, an end user may have a collection ofmobile widgets with varying levels of interaction. Based on usagepatterns, it is possible to modify update schedules for individualusers. For instance, WMC 704 may track or meter usage data that can beanalyzed by scheduling module 246 to observe that the user primarilyaccesses certain widgets. As such, based on this usage data, schedulingmodule 246 can give these widgets priority for updates. As an example,assume a user has two widgets on the widget wall: A and B. Widget Aaccess is observed at a rate of approximately once every 2 days, whileWidget B access is 3 times per day. It is possible to customize theupdate schedule in several different ways that are user specific, e.g.:(i) update Widget A and Widget B's content according to Widget B'saccess patterns, e.g. at a frequency of 3 per day prior to the observedaccess times; or (ii) update Widget B's content according to Widget B'saccess patterns, but every 2 days piggyback Widget A's update.

In another example relating to content type 256, it would most likelynot be necessary to obtain a stock widget update for a US stock after 5p.m. Eastern time, or on weekends or holidays, as the US stock marketswould be closed and thus the corresponding content update would notchange from a prior update obtained just before or at the close of theUS stock markets. Further, for example, distinct patterns of usage fordifferent content types, e.g. different categories of web content, maybe identified depending on the time and day of the week. For instance,email usage may be relatively high during weekday daytime, whileentertainment and sports may be relatively high during weeknight andweekend times.

In a further aspect, scheduling module 246 forms content update schedule248 based on a combination of operator-related considerations 252, suchas network usage patterns, end user-related considerations, such aswidget usage patterns, and content type 256, such as widget contentcharacteristics.

In another aspect, the logic, algorithms, fuzzy logic, heuristics, orneural networks, etc. of scheduling module 246 may include configurablecontention rules to balance or define priorities among competingscheduling factors 250.

In any case, update scheduling manager 244 may be operable to storecontent update schedule 248 locally, e.g. in database 128 (FIG. 4),and/or to forward content update schedule 248 to WMS 200 for storage.For example, referring momentarily to FIG. 8, WMS 200 may store contentupdate schedule 248 in digital locker 304 and/or in database 310, incorrespondence with mobile widget 102, widget catalog 302, and/orsubscriber record 314. Further, content update schedule 248 can besubsequently communicated to WMC 704 and CAS 200 in order to allow formanagement of content updates from content provider 902. Thus, in someaspects, WTC 704 receives updated content 262 from CAS 900 based oncontent update schedule 248.

It should be understood that content update schedule 248 relates toautomatic or preconfigured updates, and that an end user mayadditionally be able to manually trigger a content update at any time.

Referring to FIG. 25, in one aspect, a method 270 operable at a networkdevice for scheduling a content update of a mobile widget includesreceiving a wireless network operator-related widget updateconsideration at 272. For example, such a consideration may include timeperiods when to limit or avoid network access for content updates.

Further, the method includes generating a content update schedule for amobile widget based on the wireless network operator-related updateconsideration at 274. For example, the content update schedule mayinclude more frequent content updates during times when a network hasrelatively low network usage or relatively high network capacity, andthe schedule may include less frequent or no updates during times when anetwork has relatively high network usage or relatively low networkcapacity.

Additionally, the method includes storing the generated content updateschedule for use in updating a content of the mobile widget at 276. Forexample, the content update schedule may be stored in a memory or adatabase associated with one or both of UWM 200 and/or WMS 300 and/orCAS 900 and/or WMC 704.

Referring to FIG. 26, in one aspect, a method 280 operable at a wirelessdevice for updating content of a mobile widget includes obtaining amobile widget at 282. For example, the mobile widget 102 may bedownloaded from WMS 200.

Further, the method includes receiving a content update schedule for usein updating a content of the mobile widget, wherein the content updateschedule is generated based on a wireless network operator-relatedupdate consideration at 284. For example, WMC 704 may utilize thecontent update schedule 248 to initiate a request to CAS 900 for acontent update.

Also, the method includes receiving a content update based on thecontent update schedule at 286. For example, WMC 704 may be operable toreceive updated content 262 from CAS 900, which obtains updated content262 from content provider 902, in response to sending a request for acontent update.

Additionally, the method includes storing the content update at 288. Forexample, WMC 704 may store updated content 262 in a cache or memory ofwireless communication device 700 for use in updating a presentation ofthe content of mobile widget 102.

Turning to FIG. 27, illustrated is a system 2000 that schedules acontent update of a mobile widget. System 2000 can reside within amultiplexer, transmitter, a network device, etc., for instance. Asdepicted, system 2000 includes functional blocks that can representfunctions implemented by a processor, software, or combination thereof(e.g., firmware, etc.). System 2000 includes a logical grouping 2002 ofelectrical components that facilitate scheduling a content update of amobile widget. Logical grouping 2002 can include means 2004 forreceiving a widget update consideration. Moreover, logical grouping 2002can include means 2006 for generating a content update schedule for amobile widget based on the update consideration. Furthermore, logicalgrouping 2002 can include means 2008 for storing the generated contentupdate schedule for use in updating a content of the mobile widget.Additionally, system 2000 can include a memory 2010 that retainsinstructions for executing functions associated with electricalcomponents 2004, 2006, and 2008. While shown as being external to memory2010, it is to be understood that electrical components 2004, 2006, and2008 can exist within memory 2010.

Turning to FIG. 28, illustrated is a system 2012 that updates content ofa mobile widget. System 2012 can reside within a multiplexer,transmitter, mobile device, etc., for instance. As depicted, system 2012includes functional blocks that can represent functions implemented by aprocessor, software, or combination thereof (e.g., firmware, etc.).System 2012 includes a logical grouping 2014 of electrical componentsthat facilitate updating content of a mobile widget. Logical grouping2014 can include means 2016 for obtaining a mobile widget. In addition,logical grouping 2014 can include means 2018 for receiving a contentupdate schedule for use in updating a content of the mobile widget,wherein the content update schedule is generated based on an updateconsideration. Furthermore, logical grouping 2014 can include means 2020for receiving a content update based on the content update schedule.Moreover, logical grouping 2014 can include means 2022 for storing thecontent update. Additionally, system 2014 can include a memory 2024 thatretains instructions for executing functions associated with electricalcomponents 2016, 2018, 2020, and 2022. While shown as being external tomemory 2024, it is to be understood that electrical components 2016,2018, 2020, and 2022 can exist within memory 2024.

The various illustrative logics, logical blocks, modules, and circuitsdescribed in connection with the embodiments disclosed herein may beimplemented or performed with a general purpose processor, a digitalsignal processor (DSP), an application specific integrated circuit(ASIC), a field programmable gate array (FPGA) or other programmablelogic device, discrete gate or transistor logic, discrete hardwarecomponents, or any combination thereof designed to perform the functionsdescribed herein. A general-purpose processor may be a microprocessor,but, in the alternative, the processor may be any conventionalprocessor, controller, microcontroller, or state machine. A processormay also be implemented as a combination of computing devices, e.g., acombination of a DSP and a microprocessor, a plurality ofmicroprocessors, one or more microprocessors in conjunction with a DSPcore, or any other such configuration. Additionally, at least oneprocessor may comprise one or more modules operable to perform one ormore of the steps and/or actions described above.

Further, the steps and/or actions of a method or algorithm described inconnection with the aspects disclosed herein may be embodied directly inhardware, in a software module executed by a processor, or in acombination of the two. A software module may reside in RAM memory,flash memory, ROM memory, EPROM memory, EEPROM memory, registers, a harddisk, a removable disk, a CD-ROM, or any other form of storage mediumknown in the art. An exemplary storage medium may be coupled to theprocessor, such that the processor can read information from, and writeinformation to, the storage medium. In the alternative, the storagemedium may be integral to the processor. Further, in some aspects, theprocessor and the storage medium may reside in an ASIC. Additionally,the ASIC may reside in a user terminal. In the alternative, theprocessor and the storage medium may reside as discrete components in auser terminal. Additionally, in some aspects, the steps and/or actionsof a method or algorithm may reside as one or any combination or set ofcodes and/or instructions on a machine readable medium and/or computerreadable medium, which may be incorporated into a computer programproduct.

In one or more aspects, the functions described may be implemented inhardware, software, firmware, or any combination thereof. If implementedin software, the functions may be stored or transmitted as one or moreinstructions or code on a computer-readable medium. Computer-readablemedia includes both computer storage media and communication mediaincluding any medium that facilitates transfer of a computer programfrom one place to another. A storage medium may be any available mediathat can be accessed by a computer. By way of example, and notlimitation, such computer-readable media can comprise RAM, ROM, EEPROM,CD-ROM or other optical disk storage, magnetic disk storage or othermagnetic storage devices, or any other medium that can be used to carryor store desired program code in the form of instructions or datastructures and that can be accessed by a computer. Also, any connectionmay be termed a computer-readable medium. For example, if software istransmitted from a website, server, or other remote source using acoaxial cable, fiber optic cable, twisted pair, digital subscriber line(DSL), or wireless technologies such as infrared, radio, and microwave,then the coaxial cable, fiber optic cable, twisted pair, DSL, orwireless technologies such as infrared, radio, and microwave areincluded in the definition of medium. Disk and disc, as used herein,includes compact disc (CD), laser disc, optical disc, digital versatiledisc (DVD), floppy disk, and blu-ray disc where disks usually reproducedata magnetically, while discs usually reproduce data optically withlasers. Combinations of the above should also be included within thescope of computer-readable media.

While the foregoing disclosure discusses illustrative aspects and/orembodiments, it should be noted that various changes and modificationscould be made herein without departing from the scope of the describedaspects and/or embodiments as defined by the appended claims.Furthermore, although elements of the described aspects and/orembodiments may be described or claimed in the singular, the plural iscontemplated unless limitation to the singular is explicitly stated.Additionally, all or a portion of any aspect and/or embodiment may beutilized with all or a portion of any other aspect and/or embodiment,unless stated otherwise.

What is claimed is:
 1. A method of scheduling a content update of amobile widget, comprising: receiving a widget update considerationincluding at least a hierarchical depth to which a user of a mobiledevice navigates within the mobile widget, wherein the mobile widget isconfigured for execution on the mobile device and is independent of anyweb browsing application configured for execution on the mobile device;generating a content update schedule for the mobile widget based on thewidget update consideration; and storing the generated content updateschedule for use in updating content of the mobile widget.
 2. The methodof claim 1, wherein the widget update consideration includes a wirelessnetwork operator-related widget update consideration.
 3. The method ofclaim 2, wherein the widget update consideration comprises temporalnetwork usage data.
 4. The method of claim 2, wherein the widget updateconsideration comprises historical or projected temporal networkcapacity data.
 5. The method of claim 1, wherein the widget updateconsideration includes a widget executing device-related widget updateconsideration that is related to the mobile device configured to executethe mobile widget.
 6. The method of claim 5, wherein the widgetexecuting device-related widget update consideration comprises temporalnetwork usage data.
 7. The method of claim 1, further comprisingidentifying a content type corresponding to the content of the mobilewidget, and wherein generating the content update schedule is furtherbased on the content type.
 8. The method of claim 1, further comprisingreceiving a user content update preference, and wherein generating thecontent update schedule is further based on the user content updatepreference.
 9. The method of claim 1, further comprising receiving userupdate pattern historical data, and wherein generating the contentupdate schedule is further based on the user update pattern historicaldata.
 10. The method of claim 9, wherein the user update patternhistorical data corresponds to the mobile widget and to other mobilewidgets operable on the mobile device, and wherein generating thecontent update schedule for the mobile widget is based on the userupdate pattern historical data corresponding to at least one of theother mobile widgets.
 11. The method of claim 1, further comprisingidentifying an operational context corresponding to the mobile widget,and wherein generating the content update schedule is further based onthe operational context.
 12. The method of claim 11, wherein theoperational context comprises at least one of a time or a geographiclocation of the mobile device.
 13. The method of claim 1, wherein thewidget update consideration includes a device capability of the mobiledevice, and wherein generating the content update schedule is based onthe device capability.
 14. The method of claim 13, wherein the devicecapability comprises one of battery life or microprocessor capability orwireless connection capability.
 15. The method of claim 1, furthercomprising identifying a content type corresponding to the content ofthe mobile widget and receiving user update pattern historical data, andwherein generating the content update schedule is further based on thecontent type and the user update pattern historical data.
 16. The methodof claim 1, further comprising at least two of: (i) identifying acontent type corresponding to the content of the mobile widget; or (ii)receiving a user content update preference; or (iii) receiving userupdate pattern historical data; or (iv) identifying an operationalcontext corresponding to the mobile widget; or (v) obtaining a devicecapability of the mobile device, wherein generating the content updateschedule is further based on the at least two of: (i) the content type;or (ii) the user content update preference; or (iii) the user updatepattern historical data; or (iv) the operational context; or (v) thedevice capability.
 17. The method of claim 1, wherein the widget updateconsideration further includes a device capability of the mobile device.18. The method of claim 1, wherein the widget update considerationfurther includes a frequency at which the user accesses the mobilewidget.
 19. The method of claim 1, wherein the widget updateconsideration further includes a geographic location of the mobiledevice configured to execute the mobile widget.
 20. The method of claim1, wherein the widget update consideration further includes a geographiclocation of the mobile device configured to execute the mobile widgetand a device capability of the mobile device.
 21. The method of claim 1,wherein the widget update consideration further includes a devicecapability of the mobile device and a frequency at which the useraccesses the mobile widget.
 22. The method of claim 1, wherein thewidget update consideration further includes a geographic location ofthe mobile device configured to execute the mobile widget and afrequency at which the user accesses the mobile widget.
 23. The methodof claim 1, wherein the widget update consideration further includes ageographic location of the mobile device configured to execute themobile widget, a device capability of the mobile device, and a frequencyat which the user accesses the mobile widget.
 24. At least one processorconfigured to schedule a content update of a mobile widget, comprising:a first module configured to receive a widget update considerationincluding at least a hierarchical depth to which a user of a mobiledevice navigates within the mobile widget, wherein the mobile widget isconfigured for execution on the mobile device and is independent of anyweb browsing application configured for execution on the mobile device;a second module configured to generate a content update schedule for themobile widget based on the widget update consideration; and a thirdmodule configured to store the generated content update schedule for usein updating content of the mobile widget.
 25. A non-transitorycomputer-readable medium comprising: at least one instruction forcausing a computer to receive a widget update consideration including atleast a hierarchical depth to which a user of a mobile device navigateswithin a mobile widget, wherein the mobile widget is configured forexecution on the mobile device and is independent of any web browsingapplication configured for execution on the mobile device; at least oneinstruction for causing the computer to generate a content updateschedule for the mobile widget based on the widget update consideration;and at least one instruction for causing the computer to store thegenerated content update schedule for use in updating content of themobile widget.
 26. A network device for scheduling a content update of amobile widget, comprising: means for receiving a widget updateconsideration including at least a hierarchical depth to which a user ofa mobile device navigates within the mobile widget, wherein the mobilewidget is configured for execution on the mobile device and isindependent of any web browsing application configured for execution onthe mobile device; means for generating a content update schedule forthe mobile widget based on the widget update consideration; and meansfor storing the generated content update schedule for use in updatingcontent of the mobile widget.
 27. A network device for scheduling acontent update of a mobile widget, comprising: a communicationscomponent that includes a receiver and a transmitter, the communicationscomponent operable to receive a widget update consideration including atleast a hierarchical depth to which a user of a mobile device navigateswithin the mobile widget, wherein the mobile widget is configured forexecution on the mobile device and is independent of any web browsingapplication configured for execution on the mobile device; a processorcomponent that is configured to execute an update scheduling manageroperable to generate a content update schedule for the mobile widgetbased on the widget update consideration; and a memory componentoperable to store the generated content update schedule for use inupdating content of the mobile widget.
 28. The network device of claim27, wherein the widget update consideration includes a wireless networkoperator-related widget update consideration.
 29. The network device ofclaim 28, wherein the wireless network operator-related widget updateconsideration comprises temporal network usage data.
 30. The networkdevice of claim 28, wherein the wireless network operator-related widgetupdate consideration comprises historical or projected temporal networkcapacity data.
 31. The network device of claim 27, wherein the widgetupdate consideration includes a widget executing device-related widgetupdate consideration that is related to the mobile device configured toexecute the mobile widget.
 32. The network device of claim 31, whereinthe widget executing device-related widget update considerationcomprises temporal network usage data.
 33. The network device of claim27, wherein the update scheduling manager is further operable toidentify a content type corresponding to the content of the mobilewidget, and wherein the content update schedule is further based on thecontent type.
 34. The network device of claim 27, wherein the updatescheduling manager is further operable to receive a user content updatepreference, and wherein the content update schedule is further based onthe user content update preference.
 35. The network device of claim 27,wherein the update scheduling manager is further operable to receiveuser update pattern historical data, and wherein the content updateschedule is further based on the user update pattern historical data.36. The network device of claim 35, wherein the user update patternhistorical data corresponds to the mobile widget and to other mobilewidgets operable on the mobile device, and wherein the content updateschedule for the mobile widget is based on the user update patternhistorical data corresponding to at least one of the other mobilewidgets.
 37. The network device of claim 27, wherein the updatescheduling manager is further operable to identify an operationalcontext corresponding to the mobile widget, and wherein the contentupdate schedule is further based on the operational context.
 38. Thenetwork device of claim 37, wherein the operational context comprises atleast one of a time or a geographic location of the mobile device. 39.The network device of claim 27, wherein the widget update considerationincludes a device capability of the mobile device and wherein thecontent update schedule is based on the device capability.
 40. Thenetwork device of claim 27, wherein the update scheduling manager isfurther operable to identify a content type corresponding to the contentof the mobile widget and is further operable to receive user updatepattern historical data, and wherein the content update schedule isfurther based on the content type and the user update pattern historicaldata.
 41. The network device of claim 27, wherein the update schedulingmanager is further operable to perform at least two of: (i) identifyinga content type corresponding to the content of the mobile widget; or(ii) receiving a user content update preference; or (iii) receiving userupdate pattern historical data; or (iv) identifying an operationalcontext corresponding to the mobile widget; or (v) obtaining a devicecapability of the mobile device, wherein the content update schedule isfurther based on the at least two of: (i) the content type; or (ii) theuser content update preference; or (iii) the user update patternhistorical data; or (iv) the operational context; or (v) the devicecapability.
 42. A method of updating content of a mobile widget,comprising: obtaining the mobile widget; receiving a content updateschedule for use in updating the content of the mobile widget, whereinthe content update schedule is generated based on a widget updateconsideration including at least a hierarchical depth to which a user ofa mobile device navigates within the mobile widget, wherein the mobilewidget is configured for execution on the mobile device and isindependent of any web browsing application configured for execution onthe mobile device; receiving a content update based on the contentupdate schedule; and storing the content update.
 43. The method of claim42, wherein the widget update consideration includes a wireless networkoperator-related widget update consideration.
 44. The method of claim43, further comprising obtaining user update pattern historical data,wherein the updated content of the mobile widget corresponds to acontent type, and wherein the content update schedule is further basedon the content type and the user update pattern historical data.
 45. Themethod of claim 42, wherein the widget update consideration includes awidget executing device-related widget update consideration that isrelated to the mobile device configured to execute the mobile widget.46. The method of claim 42, further comprising: obtaining at least oneof a user content update preference, or user update pattern historicaldata, or an operational context corresponding to the mobile widget, or adevice capability of the mobile device; and transmitting to anotherdevice the respective at least one of the user content updatepreference, or the user update pattern historical data, or theoperational context corresponding to the mobile widget, or the devicecapability, wherein the content update schedule is further based on therespective at least one of the user content update preference, or theuser update pattern historical data, or the operational contextcorresponding to the mobile widget, or the device capability.
 47. Themethod of claim 42, wherein the content update schedule is further basedon at least two of: (i) a content type corresponding to the content ofthe mobile widget; or (ii) a user content update preference; or (iii)user update pattern historical data; or (iv) an operational contextcorresponding to the mobile widget; or (v) a device capability of themobile device.
 48. At least one processor configured to update contentof a mobile widget, comprising: a first module configured to obtain themobile widget; a second module configured to receive a content updateschedule for use in updating the content of the mobile widget, whereinthe content update schedule is generated based on a widget updateconsideration including at least a hierarchical depth to which a user ofa mobile device navigates within the mobile widget, wherein the mobilewidget is configured for execution on the mobile device and isindependent of any web browsing application configured for execution onthe mobile device; a third module configured to receive a content updatebased on the content update schedule; and a fourth module configured tostore the content update.
 49. A non-transitory computer-readable mediumcomprising: at least one instruction for causing a computer to obtain amobile widget; at least one instruction for causing the computer toreceive a content update schedule for use in updating content of themobile widget, wherein the content update schedule is generated based ona widget update consideration including at least a hierarchical depth towhich a user of a mobile device navigates within the mobile widget,wherein the mobile widget is configured for execution on the mobiledevice and is independent of any web browsing application configured forexecution on the mobile device; at least one instruction for causing thecomputer to receive a content update based on the content updateschedule; and at least one instruction for causing the computer to storethe content update.
 50. A mobile device for updating content of a mobilewidget, comprising: means for obtaining the mobile widget; means forreceiving a content update schedule for use in updating the content ofthe mobile widget, wherein the content update schedule is generatedbased on a widget update consideration including at least a hierarchicaldepth to which a user of the mobile device navigates within the mobilewidget, wherein the mobile widget is configured for execution on themobile device and is independent of any web browsing applicationconfigured for execution on the mobile device; means for receiving acontent update based on the content update schedule; and means forstoring the content update.
 51. A mobile device, comprising: a memorycomprising a widget management client; a processor in communication withthe memory and operable to execute the widget management client, whereinthe widget management client is operable to obtain a mobile widget,wherein the widget management client is further operable to receive acontent update schedule for use in updating content of the mobilewidget, wherein the content update schedule is generated based on awidget update consideration including at least a hierarchical depth towhich a user of the mobile device navigates within the mobile widget,wherein the mobile widget is configured for execution on the mobiledevice and is independent of any web browsing application configured forexecution on the mobile device and wherein the widget management clientis further operable to receive a content update based on the contentupdate schedule; and a database operable to store the content update.52. The mobile device of claim 51, wherein the widget management clientis further operable to receive the content update schedule from at leastone of a serving network or the mobile device.
 53. The mobile device ofclaim 51, wherein the widget update consideration includes a wirelessnetwork operator-related widget update consideration.
 54. The mobiledevice of claim 51, wherein the widget update consideration includes awidget executing device-related widget update consideration that isrelated to the mobile device configured to execute the mobile widget.55. The mobile device of claim 51, wherein the widget management clientis further operable to obtain user update pattern historical data,wherein the updated content of the mobile widget corresponds to acontent type, and wherein the content update schedule is further basedon the content type and the user update pattern historical data.
 56. Themobile device of claim 51, further comprising: obtaining at least one ofa user content update preference, or user update pattern historicaldata, or an operational context corresponding to the mobile widget, or adevice capability of the mobile device; and transmitting to anotherdevice the respective at least one of the user content updatepreference, or the user update pattern historical data, or theoperational context corresponding to the mobile widget, or the devicecapability, wherein the content update schedule is further based on therespective at least one of the user content update preference, or theuser update pattern historical data, or the operational contextcorresponding to the mobile widget, or the device capability.
 57. Themobile device of claim 51, wherein the content update schedule isfurther based on at least two of: (i) a content type corresponding tothe content of the mobile widget; or (ii) a user content updatepreference; or (iii) user update pattern historical data; or (iv) anoperational context corresponding to the mobile widget; or (v) a devicecapability of the mobile device.